Internet Surfer 2.0/Internet Surfer 2.0 (Wayzata Technology) (1996).iso/pc/text/mac/faqs.126

Text File | 1996-02-12 | 28KB | 614 lines

Frequently Asked Questions (FAQS);faqs.126



    setenv XFILESEARCHPATH /usr/lib/X11/%T/%N:$OPENWINHOME/lib/%T/%N

The value of this environment variable is a colon-separated list of
pathnames.  The pathnames contain replacement characters as follows
(see XtResolvePathname()):

    %N    The value of the filename parameter, or the
        application's class name.
    %T    The value of the file "type".  In this case, the
        literal string "app-defaults"
    %C    customization resource (R5 only)
    %S    Suffix.  None for app-defaults.
    %L    Language, locale, and codeset (e.g. "ja_JP.EUC")
    %l    Language part of %L  (e.g. "ja")
    %t    The territory part of the display's language string
    %c    The codeset part of the display's language string

Let's take apart the example.  Suppose the application's class name is
"Myterm". Also, suppose Open Windows is installed in /usr/openwin.
(Notice the example omits locale-specific lookup.)

    /usr/lib/X11/%T/%N        means /usr/lib/X11/app-defaults/Myterm
    $OPENWINHOME/lib/%T/%N    means /usr/openwin/lib/app-defaults/Myterm

As the application initializes, Xt tries to open both of the above
app-defaults files, in the order shown.  As soon as it finds one, it
reads it and uses it, and stops looking for others.  The effect of
this path is to search first in /usr/lib/X11, then in /usr/openwin.

Let's consider another example. This time, let's set
XUSERFILESEARCHPATH so it looks for the file Myterm.ad in the current
working directory, then for Myterm in the directory ~/app-defaults.

    setenv XUSERFILESEARCHPATH ./%N.ad:$HOME/app-defaults/%N

The first path in the list expands to ./Myterm.ad.  The second expands
to $HOME/app-defaults/Myterm.  This is a convenient setting for
debugging because it follows the Imake convention of naming the
app-defaults file Myterm.ad in the application's source directory, so
you can run the application from the directory in which you are
working and still have the resources loaded properly.

NOTE: when looking for app-default files with XUSERFILESEARCHPATH,
      for some  bizarre reason, neither the type nor file suffix is
      defined so %T and %S are useless.

With R5, there's another twist.  You may specify a customization
resource value.  For example, you might run the "myterm" application
like this:

    myterm -xrm "*customization: -color"

If one of your pathname specifications had the value
"/usr/lib/X11/app-defaults/%N%C" then the expanded pathname would be
"/usr/lib/X11/app-defaults/Myterm-color" because the %C substitution
character takes on the value of the customization resource.

The default XFILESEARCHPATH, compiled into Xt, is:

        /usr/lib/X11/%L/%T/%N%C:\  (R5)
        /usr/lib/X11/%l/%T/%N%C:\  (R5)
        /usr/lib/X11/%T/%N%C:\     (R5)
        /usr/lib/X11/%L/%T/%N:\
        /usr/lib/X11/%l/%T/%N:\
        /usr/lib/X11/%T/%N

(Note: some sites replace /usr/lib/X11 with a ProjectRoot in this
batch of default settings.)

The default XUSERFILESEARCHPATH, also compiled into Xt, is

        <root>/%L/%N%C:\  (R5)
        <root>/%l/%N%C:\  (R5)
        <root>/%N%C:\     (R5)
        <root>/%L/%N:\
        <root>/%l/%N:\
        <root>/%N:

<root> is either the value of XAPPLRESDIR or the user's home directory
if XAPPLRESDIR is not set.  If you set XUSERFILESEARCHPATH to some
value other than the default, Xt ignores XAPPLRESDIR altogether.

Notice that the quick and dirty way of making your application find
your app-defaults file in your current working directory is to set
XAPPLRESDIR to ".", a single dot.  In R3, all this machinery worked
differently; for R3 compatibilty, many people set their XAPPLRESDIR
value to "./", a dot followed by a slash.


----------------------------------------------------------------------
21. What order are callbacks executed in?
----------------------------------------------------------------------
(Courtesy of Donna Converse, [e-mail]; 5/10/92)

The Intrinsics library do not guarantee an order.  This is because
both the widget writer and the application writer have the ability to
modify the entire contents of the callback list.  Neither one
currently knows what the other is doing and so the Intrinsics cannot
guarantee the order of execution.

The application programmer cannot rely on the widget writer; the
widget writer is not required to document when the widget will add and
remove callbacks from the list or what effect this will have;
therefore the functionality contained in a callback should be
independent of the functionality contained in other callbacks on the
list.

Even though the Xt standard in the definition of XtAddCallback
says:

     "callback_name: Specifies the callback list to which the
     procedure is to be appended."

you may not infer from the word "appended" that the callback routines
are called in the same order as they have been added to the callback
list.

----------------------------------------------------------------------
22. How do I know if a widget is visible?
----------------------------------------------------------------------
(Courtesy of Donna Converse, [e-mail]; 5/14/92)

> I am building a widget needs to know if it is visible. I set the visible
> interest field in Core and if my window is completely obscured, the Core
> visible flag goes FALSE. However, if my window is iconified, the flag
> stays set to TRUE.

Right, everything is implemented correctly.  This demonstrates a "deficiency"
in the X protocol, and the Core widget is reflecting the capabilities of the
protocol.  (The "deficiency" is that the information is available in one way,
in this case an inconvenient way.)  The Xt specification is accurate, in
the second and third paragraphs of section 7.10.2, so read this section
carefully.  The visible field will not change in response to iconification.

A VisibilityNotify event will not be received when the window goes from
viewable to unviewable, that is, when the widget or an ancestor is unmapped;
that is, when iconification occurs.  This is the protocol deficiency.
Visibility state and viewable state have specific meanings in the X protocol;
see the glossary in your Xlib and X protocol reference manual.

> Is this a problem with "mwm" or is there something
> else which needs to be done?

You'll see this with any window manager, with no window manager.

> If the problem is "mwm", what is the fastest
> way to determine if a window is iconified?

As an application writer, keep track with a global Boolean in an action
routine with translations for MapNotify and UnmapNotify on the Shell widget
which contains your custom widget.  As the custom widget writer, see the
map_state field returned by a call to XGetWindowAttributes.  These are
suggestions.

----------------------------------------------------------------------
23. How do I reparent a widget in Xt, i.e. XtReparentWidget()?
----------------------------------------------------------------------

You can't.

----------------------------------------------------------------------
24. Why use XtMalloc, XtFree, etc?
----------------------------------------------------------------------

Unfortunately, most code that calls malloc(), realloc() or calloc()
tends to ignore the possibility of returning NULL.  At best it is
handled something like:

    ptr = (type *) malloc (sizeof (type))
    if (!ptr)
    {
        perror ("malloc in xyzzy()");
        exit (1)
    }
To handle this common case the Intrinsics define the functions
XtMalloc(), XtCalloc(), XtNew(), XtNewString() and XtRealloc() which
all use the standard C language functions malloc(), calloc() and
realloc() but execute XtErrorMsg() if a NULL value is returned.  Xt
error handlers are not supposed to return so this effectively exits.

In addition, if XtRealloc() is called with a NULL pointer, it uses
XtMalloc() to get the initial space.  This allows code like:

    if (!ptr)
        ptr = (type *) malloc (sizeof (type));
    else
        ptr = (type *) realloc (ptr, sizeof (type) * (count + 1));
    ++count;

to be written as:

    ptr = XtRealloc (ptr, sizeof (ptr) * ++count);

Also, XtFree() accepts a NULL pointer as an argument.  Generally, I've
found the Xt functions conveniant to use.  However, anytime I'm
allocating anything potentially large I use the standard functions so
I can fully recover from not enough memory errors.

XtNew() and XtNewString() are conveniant macros for allocating a
structure or copying a string:

      struct abc *xyzzy;
      char         *ptr;
      char         *str = "abcdef";

      xyzzy = XtNew (struct abc);    /* takes care of type casting */
      ptr = XtNewString (str);

Just to emphasize this, the Xt memory allocators are required to be
compatible and so interchangeable with the standard C library memory
allocators.

A common error for Motif programmers is to use XtFree() on a string
when they should really be using XmStringFree().

----------------------------------------------------------------------
25. How to debug an Xt application?
----------------------------------------------------------------------
First, I'd recomend getting "purify" from Pure Software.  This is a
great package for tracing memory problems on Sun's.  It's a bit pricey
at $2750 but I'd still recomend it.  Excuse the marketing blurb
(contact [e-mail] for more info).

    Purify inserts additional checking instructions directly into
    the object code produced by existing compilers.  These
    instructions check every memory read and write performed by
    the program under test and detect several types of access
    errors, such as reading unitialized memory, writing past
    malloc'd bounds, or writing to freed memory.  Purify inserts
    checking logic into all of the code in a program, including
    third party and vendor object-code libraries, and verifies
    system call interfaces.  In addition, Purify tracks memory
    usage and identifies individual memory leaks using a novel
    adaption of garbage collection techniques.  Purify's nearly
    comprehensive memory access checking slows the target program
    down typically by a factor of two to five.

An alternative package that isn't as pricey ($395 for a Sun), runs on
many Unix's and has pretty similar features is "The SENTINEL Debugging
Environment".  This replaces malloc() and several other C library
functions to add additional checks.  (contact [e-mail]
for more info)

Next, if you are getting any sort of Xlib error, you'll need to run in
synchronous mode, easily accompished with the "-sync" command line
argument or by setting the variable Xdebug to 1 with your debugger.  Then
set a break point in exit().  This will let you trace back to the
original Xlib function being called.  If you don't run in synchronous
mode, then the actual error may have occured any number of calls to
Xlib previously since the Xlib calls are buffered and replies from the
server are asynchronous.

Next, if you are having trouble with window layout, you can use the
undocumented resource "xtIdentifyWindows" or the class resource
"XtDebug" to cause the widget name to be identified with each window.
For example:

    example% xload -xrm '*XtDebug:true' &
    example% xwininfo -tree
         <click in new xload window>

will give the normal information but the widget name and class of each
window is included.  This can help for checking the location and size
of errant widgets.

Next, if you are having trouble with geometry managers or you want to
test the way a widget manages it's children, you can try
export.lcs.mit.edu:contrib/libXtGeo.tar.Z.  This acts as a filter
between any children and a geometry manager and checks the behaviour
of both.  It's a very clever idea.

The most unfortunate problem is debugging a callback while the
application is executing a grab of the keyboard or mouse (such as from
a pulldown menu).  The server effectively locks up and you'll need to
go to another machine and kill the debugger manually.  The server
locks up because the application being debugged has said no one else
can have access to the keyboard but the application is not stopped
waiting because the debugger is waiting for your commands.
Unfortunately you can't give them because all the input is going to
your application which is stopped.

The best way to debug this kind of problem is with two machines on
your desk, running the program under a debugger (or other environment)
on one machine, and running the application on the other, possibly
using a command sequence like this:

    othermachine% xhost +thismachine
    thismachine% setenv DISPLAY othermachine:0;
    thismachine% gdb application    # Your favorite debugger.
    or this:
    othermachine% xhost +thismachine
    thismachine% gdb application
    (gdb) set environment DISPLAY othermachine:0
    (gdb) run ...

I believe CodeCenter, a C interpreter/graphical debugger has a method
of dealing with this by explicitely calling the Xlib functions to
release any grabs during breakpoints.

Debugging widget problems requires pretty good debugging skills and
knowledge of how widgets work.  You can go a long way without knowing
the internals of a particular widget but not very far without
understanding how a widget works.  Judicious use of conditional
breakpoints and adding print statements with the debugger help a great
deal.

----------------------------------------------------------------------
26. Why don't XtAddInput(), XtAddTimeout() and XtAddWorkProc() work?
----------------------------------------------------------------------
   I have got a delicate problem with the three routines XtAddInput,
   XtAddTimeOut and XtAddWorkProc. The problem I have is that when
   I use them in my application they seem not to be registred properly.
   I have made a handy little testprogram where everything works
   perfect, but in my "real" application nothing happens.

The introduction in R3 of the XtApp*() functions obsoleted those
routines.  What happens is they use a default application context
different then the one you may have created.  Since events and
timeouts are distributed on a per application context basis and you
are using two application contexts, you won't get those events.

For example:

    ...
    cnt = 0;
    toplevel = XtAppInitialize(&app, class,
                   Desc, XtNumber (Desc),
                   &argc, argv,
                   Fallback, args, cnt);

    XtAddTimeOut (...)
    XtAddWorkProc (...)

    XtAppMainLoop (app)

would never invoke the timeout.

--
Pete Ware / Ohio State University /        228 Bolz Hall  [phone]
           [e-mail]        2036 Neil Ave.
           (h) [phone]            Columbus, OH 43210
Welcome William Patrick Ware to the world!  Born 10/21/92, 8lbs 6.2oz (3.83kg)
Xref: bloom-picayune.mit.edu comp.specification.z:623 news.answers:4293
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!mcsun!uknet!comlab.ox.ac.uk!zforum-request
From: [e-mail]
Newsgroups: comp.specification.z,news.answers
Subject: comp.specification.z Frequently Asked Questions (Monthly)
Summary: Information about the Z formal specification notation
Message-ID: <z-faq_723175204@newsserv>
Date: 1 Dec 92 02:00:10 GMT
Expires: Tue, 12 Jan 1993 02:00:04 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Followup-To: comp.specification.z
Organization: Oxford University Computing Laboratory, UK
Lines: 233
Approved: [e-mail]
Supersedes: <z-faq_720583203@newsserv>
Originator: [e-mail]

Archive-name: z-faq
Last-modified: 25 Nov 1992


NAME:     comp.specification.z
STATUS:   unmoderated
PURPOSE:  Discussion concerning the formal specification notation Z.

(If you have read this before, changed and new sections are marked with
`|' in the right hand margin.)

Questions have been marked with "Subject:" at the start of the line to
allow some newsreaders to scan them easily (e.g., "^G" within "rn").

Subject: What is it?

The comp.specification.z USENET newsgroup was established in June 1991
and is intended to handle messages concerned with the formal
specification notation Z. It has an estimated readership of around
20,000 people worldwide.  Z, based on set theory and first order
predicate logic, has been developed at the Programming Research Group
(PRG) at the Oxford University Computing Laboratory and elsewhere for
well over a decade.  It is now used by industry as part of the software
(and hardware) development process in both the UK and the US. It is
currently undergoing BSI standardization in the UK.  Comp.specification.z
provides a convenient forum for messages concerned with recent
developments and the use of Z.  Pointers to and reviews of recent books
and articles are particularly encouraged. These will be included in the
Z bibliography (see below) if they appear in comp.specification.z.

Subject: What if I know someone interested without access to USENET news?

Electronic mailing list: There is an associated Z FORUM mailing list
that was initiated in January 1986 by Ruaridh Macdonald, RSRE, UK.
Articles are now automatically cross-posted between comp.specification.z
and the mailing list for those whose do not have access to USENET
news.  This may apply especially to industrial Z users who are
particularly encouraged to subscribe and post their experiences to the
list.  Please contact <[e-mail]> with your name,
address and e-mail address to join the mailing list (or if you change
your e-mail address or wish to be removed from the list). Readers are
strongly urged to read the comp.specification.z newsgroup rather than
the Z FORUM mailing list if possible. Messages for submission to the Z
FORUM mailing list and the comp.specification.z newsgroup may be
e-mailed to <[e-mail]>.

Subject: What if I know someone interested without access to e-mail?

Postal mailing list: If you wish to join the postal Z mailing list,
please send your address to the industrial liaison secretary at OUCL,
11 Keble Road, Oxford OX1 3QD, UK (tel [phone], fax
[phone]) or on <[e-mail]>. This will ensure
you receive details of Z meetings, etc., particularly for people
without access to electronic mail.

Subject: What if I know someone interested without access to postal mail?

Be reasonable! :-)

Subject: How can I join in?

Subscribers: If you are currently using Z, you are welcome to introduce
yourself to the newsgroup and Z FORUM list by describing your work with
Z. You may also advertise any publications concerning Z which you or
your colleagues produce. These will then be automatically added to the
master Z bibliography maintained at the PRG and updated for the annual
Z User Meetings held each December.

Subject: Where are the back issues and other public Z-related files?

Archive: There is an automatic mail-based electronic archive server at
the PRG which contains all the back-issues and messages on Z FORUM and
comp.specification.z, as well as a selection of other Z-related files.
Send an e-mail message containing the command "help" to the address
<[e-mail]> for further information on how to use
the server. A command of "index z" will list the Z-related files.
If you have serious trouble accessing the archive server, please
contact the address <[e-mail]>.

FTP access: The archive is also available via anonymous FTP on the
Internet. Type the command "ftp ftp.comlab.ox.ac.uk" (or alternatively
"ftp 192.76.25.2" if this does not work) and use "anonymous" as the
login id and your e-mail address as the password when prompted. The FTP
command "cd Zforum" will get you into the Z archive directory.  The
file "README" gives some general information and "00index" gives a list
of the files. (Retrieve these using the FTP command "get README", for
example.)

Subject: What tools are available?

Tools: various tools for formatting, type-checking and aiding proofs
used Z are available.  A free LaTeX style file and documentation can be
obtained from the PRG archive server. To receive this via e-mail, send
a message containing the command "send z zed.sty zguide.tex" to the PRG
archive server (see above).  A similar style and type-checker called
fuzz are available commercially.  Send the command "send z fuzz" to the
archive server for an order form.
  CADiZ, a suite of tools for checking and typesetting Z specifications
is available from York Software Engineering, University of York, YORK
YO1 5DD, UK (tel [phone], fax [phone]). This is based
around Unix troff, but LaTeX support is planned. Contact David Jordan
at York on <[e-mail]> for further information.
  The B-Tool can be used to check proofs concerning parts of Z
specifications.  This is licensed by Edinburgh Portable Compilers Ltd,
17 Alva Street, Edinburgh EH2 4PH, UK (tel [phone], fax
[phone]). Contact the Distribution Manager on the address
<[e-mail]> for further information.  A Z proof tool called
zedB, which is based on the B-Tool, was presented at the 1991 Z User
Meeting; this may be made available in due course.

Subject: How can I learn about Z?

Courses: There are a number of courses on Z run by industry and
academia. Oxford University offers industrial short courses in the use
Z.  As well as introductory courses, recent newly developed material
includes advanced Z-based courses on proof and refinement, partly based
around the zedB tool.  Courses are held in Oxford, or elsewhere (e.g.,
on a company's premises) if there is enough demand. For further
information, contact Jim Woodcock (tel [phone], fax
[phone]) on <[e-mail]>.
  Logica Cambridge offer a five day course on Z and a three day
introductory course on formal methods (mainly Z).  For dates and prices
contact Debi Kearney on [phone] ext 4859.
  Praxis Systems runs a range of Z (and other formal methods) courses.
For details contact Anthony Hall on [phone] or <[e-mail]>.

Subject: What has been published about Z?

Publications: A BibTeX bibliography of Z-related publications is
available from the PRG archive server (see above).  Information on
Oxford University Programming Research Group (PRG) Technical Monographs
and Reports, including many on Z, is available from the librarian on
<[e-mail]>.
  The following books specifically concerning Z have been or are due to
be published (in approximate chronological order):

  I.Hayes (ed.), Specification case studies, Prentice Hall International
      Series in Computer Science, 1987.
  J.M.Spivey, Understanding Z: a specification language and its formal
      semantics, Cambridge University Press, 1988.
  D.Ince, An introduction to discrete mathematics and formal system
      specification, Oxford University Press, 1988.
  J.C.P.Woodcock & M.Loomes, Software engineering mathematics, Pitman, 1988.
  A.Diller, Z: an introduction to formal methods, Wiley, 1990.
  J.E.Nicholls (ed.), Z user workshop, Oxford 1989, Springer-Verlag,
      Workshops in Computing, 1990.
  B.Potter, J.Sinclair & D.Till, An introduction to formal specification
      and Z, Prentice Hall International Series in Computer Science, 1991.
  D.Lightfoot, Formal specification using Z, MacMillan, 1991.
  A.Norcliffe & G.Slater, Mathematics for software construction,
      Ellis Horwood, 1991.
  J.E.Nicholls (ed.), Z user workshop, Oxford 1990, Springer-Verlag,
      Workshops in Computing, 1991.
  I.Craig, The formal specification of advanced AI architectures,
      Ellis Horwood, September 1991.
  M.Imperato, An introduction to Z, Chartwell-Bratt, 1991.
  J.M.Spivey, The Z notation: a reference manual, 2nd ed., Prentice Hall
      International Series in Computer Science, 1992. (1st ed., 1989) +     |
  J.B.Wordsworth, Software development with Z, Addison-Wesley, 1992.
  S.Stepney, R.Barden & D.Cooper (eds.), Object orientation in Z,
      Springer-Verlag, Workshops in Computing, August 1992.
  J.E.Nicholls (ed.), Z user workshop, York 1991, Springer-Verlag,
      Workshops in Computing, 1992.
Announced:
  I.Hayes (ed.), Specification case studies, 2nd ed., Prentice Hall
      International Series in Computer Science, 1992.
  J.A.McDermid & P.Whysall, Formal system specification and implementation
      using Z, Prentice Hall International Series in Computer Science, 1992.
  J.C.P.Woodcock, Using standard Z, Prentice Hall International Series
      in Computer Science, 1992-93.

  + Widely considered as the current de facto standard for Z.

Subject: What is object-oriented Z?

Several object-oriented extensions to or versions of Z have been
proposed.  The book "Object orientation in Z", listed above, is a
collection of papers describing various OOZ approaches -- Hall, ZERO,
MooZ, Object-Z, OOZE, Schuman&Pitt, Z++, ZEST and Fresco (an OO VDM
method) -- in the main written by the methods' inventors, and all
specifying the same two examples.

Subject: How can I run Z?!

Z is a (non-executable in general) specification language, so there is
no such thing as a Z compiler/linker/etc. as you would expect for a
programming language. Some people have looked at animating subsets of Z
for rapid prototyping purposes, using logic and functional programming
for example, but this work is preliminary and is not really the major
point of Z, which is to increase human understandability of the
specified system and allow the possibility of formal reasoning and
development.

Subject: Where can I meet other `Z' people?

Meetings: VDM'91 was held on 21-25 October 1991, at Noordwijkerhout,
The Netherlands.  The meeting included papers on Z, and the proceedings
are available as two volumes in Springer-Verlag LNCS 551 (conference)
and 552 (tutorials). The scope of the symposium has expanded during
the last years to include other formal notations and techniques,
including Z. Therefore the name of the symposium will be changed to
Formal Methods Europe.  The first FME Symposium will be held at Odense
Technical College in Denmark, during the week of 19 to 23 April, 1993.
The programme chairman is Jim Woodcock, Oxford University Computing
Laboratory, 11 Keble Road, Oxford OX1 3QD, UK (tel [phone], fax
[phone], email <[e-mail]>). For further
details, send a message containing the command "send z fme93" to the
PRG archive server (see above).
  The 6th annual Z User Meeting was held on 16-17 December 1991, at the
University of York, England.  A 7th meeting with an industrial theme is
to be held on 14-15 December 1992 at the DTI (UK Department of Trade
and Industry), Victoria, London.  For further details, including a
registration form and information on the programme, send a message          |
containing the command "send z zmeeting92" to the PRG archive server
(see above).
  The 5th Refinement Workshop was held on 8-10 January 1992, at Lloyd's
Register of Shipping, Fenchurch Street, London, England. The proceedings
should also be published in the Springer-Verlag Workshops in Computing
series. The next workshop is planned for January 1994. Please contact
Roger Shaw on <[e-mail]> (tel [phone], fax
[phone]) for further information.
  Details of Z-related meetings may be advertised on comp.specification.z
if desired. All the above meetings are likely to be repeated in some form.

Subject: What if I've spotted a mistake or omission?

Updates: Please send corrections or new relevant information about
meetings, books, tools, etc., to <[e-mail]>.
New questions and model answers are also gratefully received!

--
Jonathan Bowen, <[e-mail]>
Programming Research Group, Oxford University Computing Laboratory, UK.
Xref: bloom-picayune.mit.edu comp.sys.acorn.announce:75 comp.sys.acorn:12768 news.answers:4663
Newsgroups: comp.sys.acorn.announce,comp.sys.acorn,news.answers,comp.answers
Path: bloom-picayune.mit.edu!enterpoop.mit.edu!snorkelwacker.mit.edu!stanford.edu!ames!haven.umd.edu!uunet!mcsun!sun4nl!star.cs.vu.nl!gpvos
From: [e-mail] (Gerben 'P' Vos)
Subject: Acorn ftp and mail-server archives (fortnightly posting)
Message-ID: <[e-mail]>
Followup-To: poster
Summary: All known Acorn-related archives on and around the Internet
Keywords: acorn,archives,ftp,mail servers
Sender: [e-mail]
Supersedes: <[e-mail]>
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Date: Sat, 19 Dec 1992 02:45:30 GMT
Approved: [e-mail],[e-mail]
Expires: Sat, 16 Jan 1993 02:45:03 GMT
Lines: 331